home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19981211-19990422
/
000226_news@watsun.cc.columbia.edu _Mon Feb 15 22:56:25 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-04-21
|
3KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA14395
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 15 Feb 1999 22:56:25 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA03362
for kermit.misc@watsun.cc.columbia.edu; Mon, 15 Feb 1999 22:33:01 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Subject: Re: Scripting F1, Downarr
Date: 16 Feb 1999 03:32:59 GMT
Organization: Columbia University
Message-ID: <7aaotb$38v$1@newsmaster.cc.columbia.edu>
To: kermit.misc@mailrelay2.cc.columbia.edu
In article <7aak94$b7j$1@samba.rahul.net>, <dold@network.rahul.net> wrote:
: Now I'm stuck in a different place. I can feed it appropriate
: down-arrows, and F1 keys to get through the menu, but the program
: itself seems to want a real terminal. If I take the .ksc up to the
: point where the program should be running, I can see that it is there
: (ps -f on Unix), but occupying no CPU time. If I "connect" from the
: script at this point, the output that I was expecting comes onto the
: screen, and it starts using CPU time.
:
: I really don't care about the output. I can check externally to see if
: the function completed successfully. In fact, in this one case, I'm
: only doing it because the program runs for over an hour, and I don't
: want to wait for it to finish ;-) If I'm at work, I just fire it off
: on an unused terminal, but from home, I can't quite get that to fly in
: the background.
You might not care about the output but the host still needs it to be
read. Otherwise, the host's output buffers will fill and the process
will block while trying to write to stdout.
Another possibility is that the host is sending queries that it expects
the terminal to respond to. If it works with K95 but not with C-kermit
this is a very strong possibility because K95's terminal emulator is
active during the INPUT command and will send appropriate responses
to terminal queries. (This behavior can be disabled in K95 with the
SET INPUT TERMINAL OFF command.)
You might want to continue this discussion via e-mail to
kermit-support@columbia.edu as the turnaround will be faster.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org